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REMARKS/ARGUMENTS 

These remarks are made in response to the fmal Office Action of May 4, 2005 (Office 
Action). As this response has been timely filed within the 3-monih shortened statutory period, 
no fee is bcHcvcd due. 

Applicaiits, an initial matter, wish to thank the Examiner for correctly noting at Page 2 
of the Office Action that the application is eligible for continued examination under 37 C.F.R. § 
1,114 and for having entered Applicants* amendment of Au£ust 6, 2004. 

At page 2 of the Office Action, Claims 1-17 were rejected mider 35 U.S.C § 103(a) as 
being unpatentable over U.S. Published Application No. 2002/0023230 to Botaick* et al 
(hereinafter Bolnick) in view of U.S. Published Application No. 2002/0016857 to Harari 
(hereinafter Harari)> and further in view of U.S. Published Application No. 2002/0098849 to 
Bloebaum ei al (hereinafter Bloebaum), 

I. Applicants' Invention 

It may be helpful to reiterate certain aspects of Applicants' invention prior to addressing 
the cited references. Applicants' invention is directed to a method, system, and apparatus for 
identifying common contacts through which people can establish relationships. Applicants' 
invention facilitates establishment of these relationships by identifying and listing contacts, such 
as social and/or business contacts, that are shared by the parties even though the parties 
themselves may be initially unaware of any specific contacts that they have in common. 

In one embodiment, contact lists of different users can be compared with one another to 
determine whether the users associated with the contact lists have any acquaintances or contacts 
in common with one another. In another embodiment, mutual contacts of different users can be 
identified despite the fact that such mutual contacts are known through several '^degrees of 
separation." Accordingly, AppUcants' invention can analyze at least two unique contact lists, 
each of which corresponds to a different user. The lists of contacts specified in one or more of 
the "original" contact lists can be retrieved and then compared with one or more contact lists 
associated with yet another party. In this marmer, multiple contact lists can be processed to 
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deiennine whether two parties are connected through, or know, "friends of friends,** Indeed, the 
process optionally can extend throu^ additional layers of contacts so that relationships can be 
established through "friends of friends of friends** and so on, (See, e.g,. Specification, p. 8, lines 
8^15.) 

U- Claims K3, And 12-14 Define Over Bolnick, Harari And Bloebaam 

Claim 1 is directed to a computerized method for generating a list of common contacts. 
The method includes first retrieving a plurality of contacts from an exposed, remotely accessible 
contact list that defines a first set associated with a user; first comparing the first retrieved 
contacts to stored contacts in a locally accessible contact list defining a second set associated 
with a different user, the first and second sets being distinct from one another; and first 
identifying common contacts among the first compared contacts. 

The method further includes a second retrieving of a plurality of contacts from an 
exposed, remotely accessible contact list associated with one of the first retrieved contacts; a 
second comparing of the second retrieved contacts to the locally stored contacts; and a second 
identifying common contacts among the second compared contacts. 

Still further, the method includes generating and storing a common contacts list 
containing the identified common contacts. The common contacts list defines yet another 
distinct set. 

Each of the steps recited in Claim 1 is now examined individually. The steps are 
examined here in the order and grouping that each is addressed in the Office Action. 

first retrieving a plurality of contacts from an exposed, remotely accessible contact list, 
the exposed, remotely accessible contact list defining a first set associated with a user 

It is asserted at page 2 of the Office Action that Bolnick discloses an identical first 
retrieving step. Paragraphs 0026-0027 and 01 70-0 1 7 1 are cited in support of the assertion. 
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Bolnick is directed to a system and method for ''providing a secure data channel between 
a user and associates" by which "pushed information from one or more associates" can be 
received from and conveyed to the user. (Para, 0025; Abstract). The "pushed information" is 
"user profile information, family definitions, and/or a hardware signature." Accordingly, as 
described throughout the reference, Bohiick is directed to providing a single, albeit updatable 
and secure^ source of information accessible to muUiple users or "associates," 

Bolnick does not teach or suggest retrieving a contact list associated with a user for the 
sake of comparing contacts culled from the contact list with cont3cts culled from a different 
contact list associated with a different user. Bolnick addresses not the retrieval of contacts for 
the sake of comparing contact lists, but rather for the conveying of information shared by 
multiple users: 

"[0026] In an exemplary embodiment of the invention, the conveyance step can 
convey information to the user using, e.g., a web interface, an interactive voice 
response (IVR) system, a wireless access device, a communications device, an 
interactive television (TV) device, a paUn top computing device, a synchronized 
device, a personal digital assistant, a computing device or another device having a 
direct and/or indirect access to the Internet. 

**[0027] In an exemplary embodiment of the invention, the method can further 
include sharing access to the personal information to an individual user or a 
ftaiily. In an exemplary embodiment, the family can include another user [or] 
multiple related users/' 

The plain language of the reference explicitly demonstrates that Bolnick is not concerned 
with the retrieval of any information for the sake of comparing the information to different 
infonnation. Instead. Bolnick is directed to the conveying of shared information, Bolnick does 
not retrieve information, but instead receives information - that is, "pushed infonnation" - so 
that the infonnation can be conveyed over "a secure channel" to a user who shares access to the 
information with other "associates*" 
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Regardless of whether conveying can legitimately be said to be the mirror image of 
retrieving, the difference between Bolnick and Applicants' invention is more than a matter of 
semantics. Without an explicit retrieval of one set of information - contacts retrieved ftom a 
remotely accessible contact list — there simply can be no comparison of contacts culled from 
different contact lists, according to the next step recited in Claim L 

first comparing said first retrieved contacts to stored contacts in a locally accessible 
contact list said locally accessible contact list defining a second set distinct from said first set 
and associated with a different user 

It is asserted at page 3 of the Office Action that Bolnick discloses an identical step. 
Paragraphs 0065-0066 and 0162-0167 of Bolnick are cited in support of the assertion. 

Bolnick nowhere describes a contact list associated with one user and a separate, different 
contact list associated with another user. Even if by happenstance the different contact lists 
comprise the same contacts, each is associated with a different user. As already pointed out, 
however, Bolnick is explicitly concerned with providing shared access to the same set of 
personal, familial, and associated information. In Bolnick, different contact lists are not 
associated with different users* Instead* different users share access to the same shared 
information. This is clear from the portions of the reference cited in the Office Action: 

"[0163] The Your Families section allows groups of people to define themselves 

as a family and share selective information with one another.'* 

"[0164] Each family can share selective portions of an up-to-date calendar, 
address/phone book, and to-do list, and can have the ability to send 
announcements, memos, postcards, letters on stationary, one-page newsletters, 
and notices of items for salc/tradc/frcc," 

The object of Bolnick is not to make comparisons, but to provide the convenience of sharing 
specific information common to each member of the family or other association of users. The 
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shared infonnation can be updated, but ultimately^ Bolnick remains a single, albeit updatable, 
source of common information to which multiple members share access: 

"[0167] The days of out-of-date contact informntion are history for site [singula] 
users [plural] since a change in a shared phone listing can be seen by all members 
who are linked to that phone listing [commonly shared]. That is. when a user 
moves down the street, all the user's "families" (e.g*, relatives, clubs, and 
organizations) and associations . . . with whom that information was shared can 
automatically be updated." 

Paragraphs 0068-0070 and 0167-0171, also cited at Page 3 of the Office Action, fttnher 
undercut any inference that BoUiick teaches or suggests the retrieving of contacts from one 
contact list associated with a user for the purpose of comparing the contacts with those from a 
distinct contact list associated with a different user. Bolnick* again, is concerned with providing 
secure access to user-supplied and user-updated information: 

"[0169] .... In essence, defined associations can replace defined families. A 
difference is that an association can sponsor the relationship and provide a secure 
link to the user's personalized infonnation," 

"[0170] For example, suppose the user has purchased a Ford Escort automobile. 
Since the auto manufacturer would like to keep up to date on the car's 
maintenance. Ford can sponsor the user purchaser's membership in the RTSN and 
can provide a secure link to real-time infonnation that is specifically personalized 
for the car . . . ." 

Nowhere in these or other portions of the reference is there any hint or suggestion of 
Bohiick's retrieving contacts from different contact lists for the sake of comparing the contacts 
culled from the separate contact lists. Instead, throughout the reference, the focus is exclusively 
on providing different users secure access to the same set of information. 
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second retrieving a plurality of contacts from an exposed, remotely accessible contact list 
associated with one of said first retrieved contacts; 

second comparing said second retrieved contacts to said locally stored contacts 

It follows that, whereas Bolnick fails to even hint at a first retrieving of contacts from a 
contact list for the sake of comparing them with contacts culled from yet a different list, Bolnick 
likewise fails to address a second retrieving and comparing. Accordingly. Bolnick also fails to 
teach or suggest either a second retrieving or a second comparing as recited in Claim 1 . 

first identifying common contacts among said first compared contacts: 

second identifying common contacts among said second compared contacts 

It is acknowledged at Page 3 of the Office Action that Bolnick fails to disclose either a 
first or second identifying step as recited in Claim 1, It is asserted, however, that this feature is 
to be found in Harari. Paragraphs 0031-0033 and 0043-0046 are cited in support of the 
contention. 

Harari is explicitly directed to an address server system that provides automatic updates 
of user contact information by way of address client interactioiis. (Para. 0006; Abstract) The 
process of automatic updating is perfomied by "an address client requesting contact information 
for a user using the address client from [a] server, and the server providing the contact 
information," (Para, 003 L) The contact information includes "a list of all persons on the user's 
contact list" as well as "an indication of status of the contacts." Upon receipt of the contact 
information from the server, the client is able to update user information and change the status of 
a contact- The status is indicated by the state of a "distribute flag." (Para. 0032) The contact 
list is updated according to the status indicated by the flag. (Para. 0033.) According to one 
embodiment of Harari, wtl address contact infomiation unit initiates a database query to locate 
and retrieve the most recent address contact information associated with the address client stored 
in the database. (Para*s, 0043-46.) 
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The explicit description of Harm throughout the reference is of a method of updating of 
individual repositories of stored information, not the comparison of contacts culled from separate 
lists of contacts. The updating perfonned by Harari is explicitly described as being based on 
status indicated by "distribute" and ''retrieve flag[s]," not on the basis of an ascertained 
commonality of members of different sets of contact lists as in Claim I: 

"[0033] If [a] contact has a distribute flag set to distribute for the user, and the 

user has set the retrieve flag to retrieve the contact's inforaiation, the address 
server determines if the update time of the associated information for the contact . 
. , is of a more recent date than the associated information in the user's data/' 

*'[0043] The address contact information unit, upon receipt of the request from 
the address client, retrieves the most recent address contact information list 
associated with the address client that is stored, and transmits the list to the 
address client," 

Accordingly, with Harari, a client merely retrieves the most current contact information. 
Har^ is devoid of any suggestion of identifying common contacts among separate contacts 
culled from different list of contacts, irrespective of whether such contacts are new. As 
explicitly described, Harari is dependent on respective users* setting different flags in order to 
indicate the updating of contact infonnation. There is no teaching or suggestion of an 
affimiative ascertainment of conunonality among different contacts from separate contact lists. 

At most. Harari merely adds detail to a process of updating of a single repository of 
contact information- It does not teach or suggest a first, let alone a first and a second, identifying 
of common contacts culled from separate contact lists as recited in Claim L 

More fundamentally, since Bolnick fails to teach or suggest a first or secotwi comparing 
of contact lists, there is no identification that can be made by Harari based on commonality 
ascertained through comparison. Accordingly, even when combined, Bolnick and Harari fail to 
teach or suggest Applicants' invention. Nothing in the conomon sharing of information hints at 
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or suggests retrieving contacts from distinct contact lists and comparing the different contacts. 
The sharing of commonly accessible information, even if updatable, is simply not Applicants' 
invention, nor does it suggest Applicants' invention, 

generating and storing a common contacts list, the common contacts list defining yet 
another distinct set and containing said identified common contacts 

It is acknowledged at Page 4 of the Office Action that the combination of Bolnick and 
Harari fails to disclose generating and storing a common contacts list. This feature, it is asserted, 
is to be found in Bloebaum. Paragraphs 0032-0034 and 0037-0039 are cited in support of the 
assertion, 

Bloebaum is directed to methods of sharing data among network-linked mobile 
communication devices based on the devices' acting as both clients and servers. (Para's. 0007- 
0010; Abstract.) The shared information ui Bloebaum is GPS-related information, such as the 
GPS satellite ephemeris and the approximate time, as well as other, application specific data. 

Bloebaum does not address the generating and storing of a list containing common 
contacts culled from different contact lists associated with different users, as recited in Claim 1. 
At most Bloebaum permits the compiling by a single mobile phone of GPS-related and other 
data obtained from other network-linked mobile phones: 

"[0029] ... a cell phone may compile the information that it needs from multiple 
sources in the group. Hence, the cell phone can put together data about different 
GPS satellites from multiple group members. The cell phone may need to sort the 
compiled data based on some criterion such as age of the assistance data. In 
another aspect of this invention, cell phones may exchange types of data other 
than GPS position-aiding type data. Exchanges of information such as phone 
numbers and e-mail addresses between phones may take place. Such exchanges 
may be generated, for example, by a high-level requirement by a user for 
synchronization between the databases of multiple phones used by the user." 
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Accordingly, Bloebaum only speaks to the compilation, sorting, and exchange of data 
from different sources. Even the compilation, exchange, and sorting of different data, however* 
lacks any suggestion as to the generation of a new set of data based on an ascertained 
commonality among different members of different sets. With Bloebaum, a mobile phone can 
access infonnation from another mobile phone, and add that information to its own set of 
information. For example, if a user wants to add or update GPS-related information or a phone 
number, Bloebaum provides a means of common access whereby the desired information can be 
obtained bom another network-connected mobile phone. This, however, does not involve 
comparing different GPS-related infonnation or different phone numbers. There is no selection 
based on a commonality between different data or phone listings. Accordingly, there is no 
selection determined by a comparison to ascertain commonality. Accordingly, there can be no 
generation or storage with Bloebaum of a distinct set containing contacts common to two 
separate contact lists, as recited in Claim 1. 

The combination of Bohiick, Harari, and Bloebaum does not yield Apphcants* invention, 
nor can the combination effect the processes of Applicants' invention. Botnick provides secure 
access to information shared among multiple "associates." The adding of Harari merely provides 
a mechanism for updating the shared infonnation. Further combining Bloebaum with Bolnick 
and Harari merely provides a mechanism whereby infomiation can be shared in a network 
setting. The combination, however, fails to teach or suggest the features recited in Claim 1. 

With Bolnick, each user supplies updates to the shared information (i.e., "pushed 
infonnation). With Harari, users must set flags for information that is to be updated. With 
Harari, users must query other users to acquire new or updated infomiation. No mechanism is 
provided for retrieving contacts from one contact list, comparing the contacts with those of 
another list, and identifying conunon contacts in order to generate yet another distinct set 
containing the contacts identified as being common to one another. 
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Applicants respectfully assert, therefore, that the asserted combination of Bolnick, Harari, 
and Bloebaum fails to teach or suggest the recited features of Claim 1 . Claims 2 and 3 depend 
from Claim I, reciting yet additional features, and thus are likewise not rendered obvious by the 
prior art. Claims 12-14 are similar to Claims 1-3, and the same arguments apply with equal force 
to these claims. Accordingly, Claims 12-14 are also not rendered obvious by the prior art 
Applicants thus respectfully request that the rejections of Claims 1-3 and 12-14 be withdrawn. 

Ih Claims 4 And 5, 15 And 16 Define Over Bolnick^ Harari And Bloebaum 

Claim 4 is directed to a method of generating a list of common contacts. The includes 
exchanging at least two contact lists over a physical communications link, each contact list 
defining a distinct set different fix>m the other and corresponding to a different user; comparing 
contacts in the exchanged contact lists to identify matching contacts; and, generating and storing 
a contact list containing matched contacts that defines yet another distinct set. 

The combination of Bolnick, Harari, and Bloebaum is also asserted, against this claim. 
Each of the steps is here examined individually in tlie order and grouping that they are addressed 
in the Office Action. 

generating and storing a contact list defining y&t another distinct set and containing said 
matched contacts 

At page 6 of the Office Action, it is asserted that Bolnick discloses a method of 
generating a list of common contacts. Paragraphs 01 15-01 18 of Bolnick are asserted in support 
of the ^scrtion. 

Bolnick does not teach or suggest generating any list, common or otherwise. Instead, the 
cited passage refers to a Real-Time-Social*Network™ that is intended to provide businesses, 
organizations, families and individuals with certain networking advantages. Nowhere is there 
any hint, however, that the advantages stem from the generation of a list of conunon contacts. In 
the cited passage, as throughout, the reference describes not the generating of a distinct set of 
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information, but instead the providing of common access to a single source of information shared 
by related members or associates: 

"[0117] Organizations [through the Real-Tim^Social-Network™] can be able to 
create a more cohesive membership through the sharing of vital information like 
an up-to-the zninute phone directoiy, calendar of events, and announcements." 

The sharing of commonly accessible information, however, is far removed from the generation 
of a new, distinct set of information, as recited in Claim 4. The sharing of a common source of 
infomiatlon has nothing to do with the generation of a new, distinct set of infomiation. Indeed, 
given that Bolnick's stated objective is to provide secure access to existing Information, it teaches 
away from the creation of new set of information: there is no motivation to create a new set if the 
existing information already exists at a source, and the only concern is to provide multiple users 
secure access to that existing information. 

exchanging at least two contact lists over a physical communications link, wherein each 
contact list defines a distinct set different from the other and corresponds to a different i4ser 

It is acknowledged at Page 6 of the Office Action, that Bolnick does not disclose the 
exchange of two or more contact lists. It is asserted, however, that paragraphs 0006-0017 of 
Harari disclose such exchanges. The cited portions describe not an exchange of two or more 
contact hsts, but rather the contribution of disparate contact information from different address 
clients to an address server. (Para. 0006,) This, however, does not teach or suggest any 
exchange of information, as recited in Claim 4. 

Indeed, the objective Harari is counter to such an exchange. Such an exchange involves 
multiple transfers of data, whereas Harari is intended to provide a central source of information 
that can be shared among multiple members, 

comparing contacts in said exchanged contact lists to identify matching contacts 
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Harari is also cited for disclosing this feature, which is acknowledged at Page 6 of the 
Office Action to be lacking in Bolnick. Paragraphs 0031-0033 are cited as containing this 
disclosiire* 

As already noted, Harari throughout the reference is of a method of updating a individual 
repositories of stored information. Accordingly, Harari does not teach or suggest comparing 
contacts contained in exchanged contact lists. Moreover, absent such exchange, it is impossible 
for Harari to identify matching contacts based on such an exchange. The updating performed by 
Harari is based on the ''distribute** and "retrieve flag[s]*^ that indicate status. But flag-designated 
status suggests nothing regarding identifying matching contacts by comparing exchanged contact 
lists, as recited in Claim 4. 

Btoebaum is cited at Page 7 as disclosing that the exchanged contact lists and the list 
generated on the basis of matching contacts can each be different sets. As already noted, 
however, Bloebaum is directed to methods of sharing data among network-linked mobile 
communication devices where each device' acts as both a client and a server. (Para's. 0007-0010; 
Abstract.) Bloebaum does not address generating and storing a distinct set based on matching 
elements contained in other sets. 

It follows that the asserted combination of Bolniok, Harari, and Bloebaum fail to teach or 
suggest every feature recited in Claim 4. Accordingly, Applicants respectfully request that the 
rejection of Claim 4 be withdrawn. Claim 5. which depends from Claim 4 while reciting 
additional features, is also not rendered obvious, and Applicants respectfully request withdrawal 
of the rejection of Claim 5 as well. Claims 15 and 16 are similar to Claims 4 and 5, and the 
arguments advanced with respect to the latter apply equally to the former. Accordingly, 
Applicants also respectfully request the withdrawal of the rejections of Claims 15 and 16. 
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IIL Claims 6 And 17 Define Over Bolnick - Harari Ai^tf p|oebamn 

Claim 6 is directed to a method of generating a list of comnaon contacts. The method 
includes accessing a contact Ust defining a set being stored in a remotely accessible database of 
contacts; comparing contacts in the contact Ust with contacts in a stored database of contacts 
defining another distinct set, the contact list and the contacts in the stored database of contacts 
each corresponding to a different user; producing matching contacts as a result of the comparing; 
and providing a visual hyperlink for each matching contact produced by the comparing step. 

The combination of Bolnick, Harari, and Bloebaum is asserted against this claim as well. 
The portions of the references cited in support of the rejection have already been addressed and 
need not be repeated in detail. Regardless of whether Bobick provides a visual hyperUnk, 
Bolnick fails to teach or suggest generating a list of common contacts. Instead, as ebeady 
observed, Bolnick is intended to provide common access to a single source of information, not 
the generation of new information, let along the generation of a contact list as recited in Claim 

Harari does not teach or suggest comparing contacts contained in separate contact lists 
associated with different users. Instead, Harari is exclusively directed to updating a single 
repository of stored information. Accordingly, Harari does not teach or suggest comparing 
contacts contained in separate contact lists as recited in Claim 6. 

Applicants respectfully maintain that the asserted combination fails to teach or suggest 
each feature of Claim 6. Accordingly, Applicants respectfully request that the rejection of Claim 
6 be withdrawn. Claim 17 is similar, and the arguments in support of Claim 6 apply equally with 
respect to Claim 17. Applicants, therefore, respectfully request that the rejection of Claim 17 
likewise be withdrawn. 
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IV. Claim 7 Defines Over Bolnick. Harari And Bloebauro 

Claim 7 is directed to a common contact identification system. The system includes at 
least two contact lists, each defining a distinct set comprising a plurality of contacts associated 
with a different user and having a publicly accessible interface through which contaista can be 
accessed remotely; a comparator for comparing contacts in each of the contact lists to identify 
matching contacts in each the contact lists; and, common contact list, resulting from the 
comparison, the common contact list defining yet another distinct set comprising contacts 
matched by said comparator. 

The combination of Bolnick, Harari, and Bloebaum is cited against this claim as welL 
The asserted combination, however, fails to teach or suggest each of the features recited in Claim 
7, As shown above, none of the references teach or suggest, for example, comparing contacts 
culled from separate contact lists in order to identify matching contacts. 

More particularly, the personal digital assistant (PDA) in FIGS. 7 and 9, as well as the 
text portions of Bohiick cited at Page 10 of the Office Action, do not suggest a comparator as 
recited in Claim 7. Instead, what is described in Bolnick is a "user interface" and *'user home 
page:" 

"[0238] FIG. 9 depicts a block diagram 900 illustrating an exemplary 
embodiment of a user interface illustrating an exemplary web-based version of a 
user's summary 'your home' home page ... of the present invention. The view 
can include, e.g., new messages 906, a to-do list 904, and a calendar 902. FIG. 9 
also illustrates interfaces easily ported to a personal digital assistant (PDA) 908, 
910." 

The cited portions merely reiterate that Bolnick is concerned not with identifying matches 
between different contacts culled from different contact lists, but rather with the secure sharing 
of updatable information with various "associates." Nothing in Bolnick suggests or even hints at 
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a comparator capable of comparing contacts in different contact lists to identify matching 
contacts in the contact lists. 

Accordingly, Applicants respectfully maintain that the cited art fails to render Claim 7 
obvious. Applicants, therefore, respectfully request that the rejection of Claim 7 be withdrawn. 



The Applicants believe that this application is in full condition for allowance, which 
action is respectfully requested The Applicants invite the Examiner to call the undersigned if 
clarification is needed on any maner within this Amendment, or if the Examiner believes a 
telephone interview would expedite the prosecution of the subject application to completion. 



CONCLUSION 



Respectfully submitted. 





Gregory A. Nelson, Registration No. 30,577 

Richard A. Hinson, Registration No. 47,652 

AKERMAN SENTERFITT 

Customer No. 40987 

Post Office Box 3188 

West Pahn Beach. FL 33402-3188 

Telephone: (561) 653-5000 
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